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EXECUTIVE  SUMMARY 


Technology  development  is  a large  segment  of  activity  within  the  DoD. 
In  general  terms  this  base  of  work  is  maintained  to  enhance  our  capability 
to  field  systems  adequate  to  meet  future  sophisticated  threats.  It  follows 
that  technology  transition  is  vital.  Within  the  spectrum  of  R5D  programs 
conducted  by  the  DoD  there  are  "sets”  of  research  which  might  properly  be 
classified  as  large  technologies  and  small  technologies.  Possibly  the 
distinction  originates  in  how  urgently  the  technology  is  needed  for  current 
development  programs.  In  any  case,  the  large  technologies  are  invariably 
linked  to  major  programs  and,  per  se,  need  no  driving  force  to  sustain 
or  justify  the  major  research  work.  There  is  no  question  of  technology 
transfer  here,  since  utilization  is  demonstratable  in  major  systems. 

At  the  fringes  of  the  large  technology  programs,  and  in  broad  areas 
where  major  thrusts  do  not  currently  exist  there  are  hundreds  of  small 


programs  underway  in  all  of  the  services  that  exist  under  the  aegis  that 
they  will  be  required  in  the  future.  These  are  defined  as  Small  Technolgies. 
In  point  of  fact,  all  of  these  technologies  are  useful,  all  are  interesting, 
all  do  possess  potential,  but  are  probably  not  being  applied  efficiently. 

The  blight  on  technology  transfer  is  primarly  a two  fault  syndrome. 
Program  managers  view  small  technologies  at  face  value  and  see  a welter  of 
conflicting  data,  theories,  pheonomenlogical  explanations.  The  program 
office,  consequently,  discards  small  technologies  as  unusuable.  Managers 
of  small  technologies  allow  this  to  happen.  Herein  lies  the  cause  of  the 
demise  of  technology  transfer. 

Small  Technology  Management,  as  set  forth  in  this  paper,  is  a personal 
management  attitude  (philosophy)  that  can  circumvent  this  turn  of  events. 


i i 


This  attitude  embraces  a "will  do"  concept  toward  the  responsibi Ities 
associated  with  making  technology  acceptable  for  use  in  Department  of 
Defense  systems  acquisition  programs.  The  system  acquisition  manager  must 
match  this  attitude  just  as  responsibly,  and  accept  technolgies  which  are 
ready  for  use  although  still  "immature"  in  the  sense  of  systems  applications. 

By  successfully  integrating  this  theme  of  attitudes,  the  Small  Tech- 
nology Manager  can  bring  focus  to  his  technology  area.  He  can  define  the 
area  usages  of  his  Small  Technology,  can  determine  and  direct  development 
work  that  the  user  community  needs,  can  orient  his  research  toward  future 
applications.  In  short,  he  can  provide  the  vision  to  consolidate  develop- 
ments into  useful  application  (transfer  technology  now)  and  can  create 
research  goals  more  clearly  directed  to  futuve  needs  (future  technology 


transfer) . 
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Formalized  Technology  Transfer 


Federally  funded  research  and  development  has,  during  the  second  half 
of  the  20th  Century,  become  a significant  industry  unto  itself.  Funds  slated 
for  expenditure  in  1978  are  approximately  $11,904  billion  dollars  of  budgeted 
Department  of  Defense  funds  plus  an  estimated  additional  expenditure  of  5-6 
of  contractor  sales  to  the  federal  government  for  Independent  Research  and 
Development  and  Product  Improvement.  In  recent  years  private  industry,  as 
well  as  the  Department  of  Defense,  have  drifted  towards  the  connotation 
that  research  and  development  must  be  so  structured  that  no  significant 
failures  occur  during  program  execution.  High  emphasis  is  placed  on 
"successful"  R8D  to  the  extent  that  there  is  an  unreasonably  low  tolerance 
level  for  failures  and  little  management  initiative  to  budget  realistically 
for  false  starts  or  learning  curve  advancement  in  a technology  sense.  The 
Department  of  Defense  - in  its  ever  increasing  tendency  to  disallow  the  risk 
connotation  to  the  phrase  "research  and  development"  is  met  at  the  govern- 
ment industry  interface  by  a similar  industry  attitude.  The  pressure  within 
industry  to  maintain  its  return  on  investment  levels  with  previous  years 
is  creating  two  new  corporate  attitudes.  (1)  Industry  has  little  accept- 
ance, in  the  current  state  of  technology,  of  governments  position  that  it 
should  share  the  risk  of  technology  innovation  and/or  invention  for  products 
in  the  government  arena.  This  shifts  the  financial  responsibility  almost 
totally  onto  the  government  for  bearing  the  risk  associated  with  advanced 
technology  required  for  weapon  systems  which  must  (always)  meet  out-year 
threats  embodying  sophisticated  technological  advances.  (2)  Industry  is 


moving  towards  a "OoO  attitude"  with  regard  to  its  own  commercial ly  oriented 
technology.  I'hat  is,  it  is  imposing  more  pressure  in  its  own  exploratory 
development  programs  to  eliminate  the  risk  from  research  and  development. 

The  impact  here  is  that  the  broad  base  of  technology  is  being  curtailed  in 
favor  of  a narrower  range  of  funded  programs  that  will  pay-off  with  the 
least  risk,  and  quickly. 

There  is  a growing  concern  within  the  Department  of  Defense  relative 
to  technology  transfer.  More  particularly:  towards  showing  appropriate 
levels  of  transfer  - of  expended  dollars  in  terms  of  improved  capa- 
bility military  s-  igress,  on  the  other  hand,  constantly  exerts 

pressure  on  the  teUcral  RfiD  community  (primarily  DoD,  ERDA,  .NASA)  to  show 
civil  benefits  from  such  expenditures.  The  reaction,  among  the  federal 
agencies,  is  to  show  relevancy  of  funded  research  to  major  acquisition  pro- 
grams and  to  minimize  comments  and  visibility  of  R5D  enterprises  that  are 
false-starts , have  no  immediate  application,  or  which  require  massive  over- 
haul to  obtain  salient  results.  Little  effective  resistance  has  been 
mounted  to  halt  the  increasing  curtailment  of  "non-relevant"  R^D. 

The  process  is  a vicious  circle:  Congress  authorizes  and  appropriates 

monies  and  exerts  pressure  to  justify  expenditures.  .Agencies,  in  todays 
environment,  satisfactorily  justify  only  expenditures  which  have  "immediate" 
payoff.  On  a yearly  basis  more  and  more  ROD,  that  which  cannot  be  umbrellaed 
by  the  assertion  of  future  threat  sophistication  or  greater  future  societal 
need  satisfaction,  is  postponed  or  written  off  the  books.  The  impact  of 
this  trend  will  not  be  felt  now.  In  fact,  it  will  not  be  felt  while  the 
current  elected  are  in  power.  The  effects  of  risk  avoidance  in  R5D  will 
materialize  in  a decade,  or  in  two  decades.  Acquisition  of  technical  know- 
ledge, accumul-ited  to  underwrite  future  systems  developments,  is  being 
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tion.  Teclinology  diffusion  - the  time  consuming  process  of  dissemination 
of  concentrations  of  technical  knowledge  - is  a significant  factor  under- 
lying the  process  of  technology  innovation.  If  there  are  no  new  concentra- 
tions of  knowledge  to  be  diffused  within  our  science  and  engineering  communi- 
ties, there  will  be  little  new  application  potential  after  a time. 

Devising  a method  to  promote  the  flow  of  RfiD  results  into  application 
is  extremely  difficult  - probably  impossible,  except  in  isolated  highly 
focused  instances.  .N'one  the  less,  numerous  models  have  been  devised,  numer- 
ous investigations  have  been  executed  to  develop  and  substantiate  methods 
of  accelerating  the  flow  of  technology  from  the  researcli  community  into 
the  application  community.  Most  models  for  technology  transfer  present 
structured  information  systems  to  aid  the  flow  of  ideas  into  arenas  whore 
they  can  be  applied.  These  models  reveal  the  unquanti fiable  (and  mysterious) 
element  of  human  endeavor.  These  models  reveal,  almost  by  surprise,  that 
entrepreneurship,  ingenuousness  and  inventiveness  - human  elements  - underwrite 
most  innovations.  The  bulk  of  this  article,  which  is  about  technology 
transfer,  will  deal  with  the  human  element  side  of  the  transfer  issue. 
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SECTION  II 
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EXPOSITION 


IVhat  Is  a "Small  Technology"? 

This  paper  deals  with  a facet  of  management  required  in  the  research 
and  development  field  within  the  Department  of  Defense.  This  paper  deals 
with  the  small  dollar  programs  which  comprise  approximately  80%  of  the 
"roadmapped"  R^D  programs  in  the  military  laboratory  community.  Each  of 
these  programs  (frequently  comprising  3 or  4 contracts  or  a comparable  amount 
of  inhouse  work),  is  small  in  dollar  magnitude,  paced  over  a 3 to  5 year 
period  of  time,  and  may  compliment  other  such  programs  but  can  probably 
stand  alone  as  a "defendable"  program.  This  paper  does  not  deal  with  programs 
(small  or  large)  which  are  in  the  limelight  by  virtue  of  external  agency 
interest  or  current  need.  This  paper  develops  management  tenets  for  those 
first  level  managers  of  small  technology  programs  as  well  as  first  level 
system  managers  who  have  a need  for  technological  improvements  and  cites 
attitudinal  attributes  which  technology  program  managers  should  cultivate  or 
possess  to  a high  degree. 

A Small  Technology  (ST)  is  defined  here  as  a collection  of  interrelated 
small  dollar  R^D  programs.  Characteristics  of  small  technologies  are: 

(1)  clearly  defined  research  objectives  - probably  for  some  future  applica- 
tion, (2)  a continuity  of  need  - past,  present,  future  - which  provides  pro- 
gram continuity,  (3)  distinct  emphasis  on  the  exploratory  nature  of  the 
program,  (4)  a considerable  degree  of  empiricism  at  the  forefront  of  the 
technology  associated  with  emerging  quantification  in  the  older  portions  of 
the  overall  program  (5)  a modest  private  sector  involvement  in  terms  of 
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interested  (capable)  contractors,  and  (6)  modest  research  funding.  Addi- 
tionally, and  most  critically,  a small  technology  has  no  immediate  outlet 
as  relates  to  direct  system  application,  i.e.,  no  system  in  the  acquisitii  r 
process  has  accepted  this  technology  for  use  in  its  current  state  of  advance- 
ment . 

It  is  contended  that  small  technologies,  as  defined,  are  prey  to 
several  influences  which  can  stifle  a primary  objective  of  Department  of 
Defense  sponsored  RDD,  namely:  transition  to  application.  One  recogniccs 
that  within  broad  constraints  the  technology  base  must  be  protected  from 
the  ever  present  question  of  "where  arc  you  going  to  use  that?"  This  is 
utterly  essential  to  the  well  being  of  the  nation's  defense  posture  - 
particularly  in  the  future.  However,  the  persistence  with  which  the  R&D 
community  is  assaulted  by  the  above  question  gives  a clue  that  some  perceive 
a deficiency  in  the  function  of  transition  of  Rf)D  to  application.  Small 
technologies  can  become  institutionalized,  can  run  on  year  after  year 
generating  empirical  data  which  literally  litters  the  investigative  field, 
are  nonst ructured  in  tlieir  explorative  nature,  are  incomprehensible  to  any 
outside  the  technology.  Small  technologies  can  become  introspective  - 
generating  research  issues  and  answers  of  relatively  little  interest  vis  a 
vis  application.  Small  technolgies  can  get  well  out  of  touch  with  comparable 
work  occurring  in  industry  or  in  sister  services. 

It  is  contended  that  a primary  management  role  in  the  conduct  of  small 
research  and  development  programs  is  the  internal  application  of  the  question 
"where  are  we  going  to  use  this?"  It  is  asserted  that  the  proper  local 
application  of  this  question  and  appropriate  activities  to  develop  the 
answer  to  this  question  - and  action  in  accordance  witli  the  answer  developed  - 
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will  strengthen  the  umbrella  over  R^D  which  protects  it  from  being  arbi- 
trarily redirected  or  terminated.  It  is  assorted  that  application  rate  can 
be  improved  and  that  healthier  R5U  (for  long  term  objectives)  can  result. 

This  paper  will  set  forth  a "small  technologies  management”  approach  (attitude) 
as  a fundamental  management  precept  (the  Small  Technology  Manager  (STM) 
approach)  for  Department  of  Defense  sponsored  RliD. 

h'ho  Is  the  Small  Technology  Manager? 

The  vertical  orientation  of  management  and  functional  definition  which 
e.xists  in  agencies  patterned  after  Webers'  Bureaucratic  model,  provides  a 
key  element  to  the  emergence  of  the  Small  Technology  Management  concept.  At 
the  first  level  of  supervision  wo  find,  in  most  government  laboratories,  and 
in  many  corporate  agencies  involved  in  technology  development,  a pivotal 
interface,  a "dual -manning"  area.  In  those  organizations  there  are  essentially 
two  career  progression  avenues:  science  and  engineering  development  or  tech- 
nical management.  The  talented  personnel  in  the  working  ranks  exhibit 
P’.oclivities  towards  technology  or  management.  As  senior  personnel  move  up, 
the  young  engineers  with  a management  orientation  move  into  first  level 
supervisory  oppotunit ies . They  are  conversant  with  the  technology  of  the 
groups  they  supervise  (having  just  come  from  them) , they  have  no  time  to 
practice  technology,  but  have  time  to  stay  abreast  of  it.  They  respond,  by 
job  charter,  to  traditional  bureaucratic  demands  on  management.  Their 
scientifically  oriented  counterparts,  in  the  meantime,  ascend  to  leadership 
roles  in  steering  technology  areas.  They  become  technical  area  managers. 

They  do  not  provide  the  supervisory/administrative  function  to  people,  but 
do  provide  this  function  to  their  technical  areas.  They  are  occupied  by 
duties  which  require  reporting  and  planning  and  remaining  leaders  in  their 


technology  areas.  They  work  for  their  counterparts  - the  first  level  super- 
visors. The  significant  point  here  is  the  "duality"  of  the  interface  in 
terms  of  general  knowledge  of  the  technology. 

Consider  such  a "pair"  - a first  level  supervisor  and  his  technical 
area  manager.  One  of  these  two  people  will  be  saturated  with  duties.  Gener- 
ally it  is  the  technical  area  manager.  He  must  stay  technically  proficient, 
he  must  plan,  program,  budget  for  his  continuing  research,  he  must  (almost 
continually)  defend,  explain,  bargain  with  the  upper  agency  management  to 
keep  his  technology  area  funded.  On  the  other  hand,  the  first  level  super- 
visor does  not  have  as  intense  a burden.  He  does,  however,  possess  a working 
knowledge  of  the  technical  area  and  he  has  management  ability  (business 
sense  and  people  sense).  He  is  the  prime  candidate  to  assume  the  Small 
Technology  Manager  (STM)  role. 

The  STM  Attitude 

What  does  this  candidate  do  when  it  finally  dawns  on  him  that  the  tech- 
nology his  work  force  is  developing  may  never,  or  at  least  not  very  rapidly, 
be  promulgated  into  useful  applications?  What  is  the  consequence  of  waiting 
until  a potential  user  comes  knocking  on  his  door?  In  fact,  how  long  is  he 
likely  to  wait  for  such  a knock?  Will  his  management  put  pressure  on  him 
to  apply  his  technology?  For  the  moment  let  us  discuss  the  attitude  that 
ought  to  exist  in  the  STM,  the  attitude,  and  the  reason  that  the  attitude 
can  survive  and  grow. 

Stated  simply,  the  attitude  is  "you  don't  need  permission  to  transfer 


your  technology".  So,  don't  wait  to  be  told  to  apply  it.  Don't  ask  per- 
mission to  sell  it.  Don't  give  up  on  upper  level  management  interest  in 
applying  a technology  - simply,  don't  wait  for  an  outside  assertion  to  apply 


technology.  The  simplest,  most  direct  approach  to  doing  something  useful 
is  to  go  do  it,  ask  permission  later  ...  or  not  at  all.  If  you  define  tech- 
nology transition  as  one  of  the  roles  in  your  functional  province,  you  need 
neither  permission  nor  overt  management  concern  that  you  seek  application 
outlets.  Piligently  pursued,  technology  outlets  will  accrue  (by  definition 
DoD  sponsored  R^D  has  useful  system  application  - some  place(s)).  With 
success  in  applying  new  technology  to  a ■system  the  will  to  make  technology 
more  broadly  serviceable  will  also  grow.  The  "do",  rather  than  the  "think- 
about"  attitude  of  technology  transfer  will  be  secured. 

IVhat  Does  the  STM  Do? 

Certain  steps  are  essenczal  to  the  successful  entrepreneurship  of  a 
small  technology.  The  focus  is  on  the  manager  as  an  individual  - not  as  a 
part  of  an  agency  - and  the  dominent  attitude  is  personal  accomplishment  of 
the  steps  (or  stages)  cited.  The  manager  must  prepare  himself,  must  emerge 
from  organication  attitudes,  must  live  the  attitude  that  he  is  best  suited 
(and  situated)  to  deliver  technology  to  application,  that  it  is  his  responsi 
bility  to  do  this. 

Global  Perception  of  the  ST 

Due  to  the  proliferation  of  technology  sponsored  throughout  the  DoD 
laboratory  structure,  there  is  almost  no  possibility  that  the  research 
central  to  a given  ST  is  practiced  only  by  the  would  be  entrepreneur's  group 
As  the  initial  step  in  assuming  the  role  of  transition  practitioner,  the 
STM  must  become  familiar  with  the  extent  and  content  of  the  technology  as 
pursued  within  other  government  laboratories.  Almost  without  question  tliis 
will  require  a definite  ability  to  estziblish  rapport  with  coworkers  in  the 
same  field.  A hallmark  of  bureaucratically  oriented  government  laboratories 
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is  the  innate  proclivity  towards  noncommunication  with  technically  qualified 
"other"  agency  personnel.  Probably  the  root  cause  of  this  is  professional 
pride  linked  with  new  ideas  in  research  which  are  frequently  difficult  to 
originate  and  harder  yet  to  sell  to  management.  One  will  not  talk  freely 
on  such  topics  if  he  feels  he  is  likely  to  see  these  ideas  emerging  in 
another  agency's  research  program  a year  later.  Yet  it  is  absolutely  im- 
perative that  a working  knowledge  of  the  research  objectives  (and  methods) , 
as  practiced  by  other  governmental  agencies,  be  obtained. 

The  search  for  these  areas  of  similar  research  sliould  extend  into 
organizations  chartered  to  basic  research  (6.1),  exploratory  development  (6.2) 
and,  quite  likely  advanced  development  (6.3).  The  search  should  extend  at 
least  across  all  military  services.  By  acquiring  an  insight  into  what  the 
DoD  is  really  doing  in  a given  research  area,  other  necessary  information 
will  accumulate:  the  private  sector  involvement,  the  scope  of  resources 

being  pplied  to  the  field,  the  uniformity  (or  in  many  cases,  the  duplication) 
of  effort  being  applied  to  the  various  aspects  of  the  technology.  Addition- 
ally, knowledge  of  people  will  result:  the  government  and  private  sector 

practitioners  of  the  research,  the  government  people  attempting  to  utilize 
the  technology  being  developed  ...  and  these  people  will  attain  a knowledge 
of  the  STM.  Finally,  insight  will  be  accrued:  areas  where  the  technology 
can  (or  sliould)  be  applied,  perceived  deficiencies  of  the  technology  as 
viewed  by  would  be  users,  the  extent  and  content  of  research  performed. 

The  STM's  own  perception  of  technology  deficiencies  relative  to  suitability 
for  application  will  emerge  in  this  process. 

System  Needs  for  Small  Technology  Application 

E-stablishing,  at  least  in  the  STM's  mind,  what  systems  could  benefit 
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from  application  of  a new  technology  is  the  acid  test  for  justification  of 
government  expenditure  in  the  technology  area.  It  is  inconceivable  that,  in 
the  steps  taken  to  understand  the  breadth  and  scope  of  the  technology  inves- 
tigations underway  in  the  government  and  private  sectors,  a range  of  applica- 
tions cot  be  discovered.  This  range  will  include  hacily  defined  long  term 
objectives,  shorter  range  firm  application  targets,  and  probably  some 
application  of  previous  de/elopments  (within  the  same  technology  which  could 
be  improved  upon.  A given  technology  generally  presents  a continuum  of 
achievements  which  range  from  older  work  which  resulted  in  uses  and  applica- 
tion of  the  technology  (past  transferred  technology)  to  current  work  which 
may  be  ready  for  application. 

The  ejiiphasis  of  the  STM  should  be  in  providing  outlets  for  the  emerging 
technology  across  a greater  spectrum  of  applications  and  into  system  applica- 
tions which  are  new  for  the  ST.  Innovation  and  tailoring  of  the  technology 
must  ultimately  be  accomplished  to  acquire  suitability  for  application  in 
new  systems  developments.  There  are  generally  many  market  places  which  have 
historically  resisted  utilization  of  the  ST.  The  reasons  are  predictable: 
"work  not  fully  developed",  "costs  too  much  to  be  utilized",  "looks  good, 
but  still  too  immature  to  risk  during  system  development",  "we  have  too 
many  major  risk  areas  to  worry  about  another".  These  are  standard  refrains 
that  technology  managers  receive  from  system  program  managers.  A major 
reason  for  these  responses  is  that  the  ST  is  not  proposed  in  acceptable 
fashion  to  the  systems  managers.  And  this  is  the  technology  manager's  fault. 

Understand  the  system.  A general  notion  of  how  the  ST  can  be  applied 
is  simply  not  good  enough.  The  STM  must  have  a detailed  understanding  of 
the  system  he  wants  to  impact.  He  must  know  the  mission  of  the  system,  the 
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mission  profiles,  the  environment  the  system  operates  in,  the  acquisition 
phase  the  system  is  in,  the  schedule  of  events  that  the  system  is  constrained 
by,  the  fiscal  constraints  imposed  on  the  system  development.  If  the  ST 
is  hardware  oriented,  it  is  essential  to  understand  the  production,  main- 
tenance, and  reliability  plans  of  the  system  to  be  impacted.  In  short,  the 
STM  must  understand  the  system  well  enough  so  that  he  can  evaluate  the  ST 
from  the  same  point  of  view  as  the  system  manager.  The  STM  must  wear  a 
"systems  hat"  when  he  considers  whether  the  ST  is  applicable  to  a system. 

There  are  numerous  information  sources  available  to  provide  insight 
into  a major  system  program.  An  essential  first  (and  continuing)  source  of 
information  is  people.  People  in  the  system  program  office(s).  Get  to 
know  the  people  in  the  program (s)  since  these  are  the  ones  who  will  open  or 
close  the  door  to  utilization  of  the  ST.  Through  knowledge  of  the  people, 
knowledge  of  the  program  details  can  be  obtained.  Program  requirements, 
schedules,  test  plans,  specifications  all  can  be  acquired  by  asking.  More 
important,  the  STM  can  evaluate  the  people.  He  can  determine  the  special 
emphasis  they  place  on  the  ST  as  they  perceive  it,  how  they  evaluate  its 
shortcomings,  and  what  the  attitude  is  concerning  costs  and  schedules.  The 
STM  can,  finally,  educate  the  program  development  people  relative  to  the 
ST  - as  he  is  educating  himself  relative  to  the  program  he  wishes  to  impact. 
Small  Technology  Needs  for  System  Application 

It  is  almost  axiomatic  that,  for  multi-agency  pursued  technologies,  the 
body  of  research  and  experimental  knowledge  is  not  adequately  collected, 
integrated  and/or  uniformly  understood.  This  is  especially  likely  in  emer- 
gent technologies  that  are  spearheaded  by  empirical  research  and  which 
possess,  at  best,  emerging  analytical  and  phenomenological  descriptions  of 
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aspects  of  the  technology.  The  STM,  in  obtaining  a global  perception  of 
the  ST,  must  be  aware  of  numerous  "indicators"  of  the  maturity  and  cogency 
of  it.  For  instance,  he  will  be  aware  of  the  different  broad  disciplines 
practiced  within  the  technology  - disciplines  required  to  analyze  perfor- 
mance capability  in  diverse  operational  environments.  He  will  be  aware  of 
conflicting  emerging  theories  relative  to  performance.  At  the  forefront 
of  a technology  this  degree  of  "theory  confusion"  is  normal  and  is  recon- 
ciled only  over  long  periods  of  time  because  budgets  are  normally  small. 

The  STM  will  be  aware  of  diverse  test  methods  in  use,  of  data  bases 
related  to  these  test  methods,  and  of  (often)  uncorrelatable  results  be- 
tween the  different  test  methods.  He  will  be  aware  of  data  base  "sets"  used 
by  different  government  laboratory  agencies  - these  sets,  while  not  mutually 
exclusive,  do  not  include  uniformly,  the  major  advances  made  in  all  labora- 
tories. The  STM  will  also  be  aware  of  tost  methods  which  are  affordable, 
but  which  do  not  duplicate  the  system  use  environment.  Most  tests  are  this 
way.  This,  in  conjunction  with  a host  of  extrapolative  techniques  by  which 
test  results  are  extended  to  encompass  real  environments  provides  weakly 
supported  performance  data. 

Just  as  he  will  perceive  the  above  mentioned  indicators  of  newness 
and  growth  within  his  technology,  the  STM  will  also  grasp  the  established 
elements  of  the  ST,  the  new  proven  concepts,  the  documented  improvements  over 
previous  years,  the  proven  analytical  methods  and  phenomenological  theses. 

He  will  know  where  the  technology  has  been  applied  and  will  know  what  new 
advances  have  not  been  applied. 

The  STM,  as  he  compares  what  he  knows  about  the  state  of  his  technology 
with  what  he  perceives  as  likely  systems  developments  that  could  (should) 
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"h  apply  his  technology,  is  in  a position  to  analyze  why  the  technology  is  not 

being  employed.  If  the  STM  does  his  job  properly  at  this  point,  he  can  hasten 
transition  by  years.  His  role  is  one  of  assessing  the  ST  for  true  usefulness 
to  defense  systems  under  development.  He  must  look  inward  at  the  technical 
community  and  its  results  and  ask  whether  the  work  he  fronts  for  is  ready 
for  engineering  development.  More  importantly,  he  must  determine  whether 
or  not  it  appears  viable.  In  essense,  the  STM  must  be  somewhat  eclectic  in 
his  approach,  he  must  act  as  a buffer  between  the  technology  community  and 
the  user  community.  He  must  prevent  the  extreme  forefront  of  his  technology 
(where  the  confusion  exists)  from  being  presented  as  useful  to  the  systems 
developer.  It  is  not,  by  virtue  of  the  unresolved  nature  of  it.  Ho  must 
focus  the  new  and  substantiated  results  for  the  system  developers'  considera- 
tion. He  must  present  these  results  in  a frame  of  reference  that  the  user 
community  can  grasp,  that  is,  he  must  use  their  language,  their  constraints, 
their  environment. 

In  the  performance  of  this  role,  the  STM  should  become  adept  at  wearing 
"two  hats".  He  must  be  able  to  wear  a "system  hat"  when  viewing  the  ST  for 
possible  application,  and  he  must  wear  his  customary  "technology  hat"  at 
other  times.  It  is  entirely  possible  that  his  assessment  of  the  ST,  when 
he  views  it  as  a potential  user,  is  that  there  are  gaps  in  the  technology, 
untested  or  unexplored  regions  that  must  be  resolved  to  strengthen  the  appeal 
of  the  technology  to  the  user.  In  truth,  this  is  a point  of  view,  an  insight, 
most  often  lacking  in  the  technical  community.  There  is  generally  no  per- 
ception of  how  inadequate  the  technology  appears  (or  is,  actually)  to  the 
would  be  user. 

The  STM  Charter 

The  STM  can  provide  two  invaluable  (and  rarely  performed)  services 
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to  the  technical  community  he  represents.  He  has  learned  what  potential 
users  exist  in  the  systems  acquisition  community  as  well  as  their  needs, 
their  constraints,  their  views  and  requirements.  Secondly,  he  has  evaluated 
the  ST  from  a user  orientation  and  can  perceive  technology  gaps  that  must 
be  filled  or  overcome  - he  has  the  user  view  of  why  the  technology  cannot 
be  applied.  Almost  by  accident  he  has  gained  a viewpoint  that  most  govern- 
ment researchers  do  not  possess.  And  the  impact  this  viewpoint  can  have 
on  the  ST  is  immense.  Now  it  is  possible  to  define  explicitly  the  reason 
for  existence  of  the  ST.  Such  requirements  as  specific  systems  applications, 
specific  needs,  specific  time  frames  for  application,  broader  user  base,  now 
become  part  of  the  ammunition  used  by  the  technical  community  to  protect  and 
extend  their  technology  budget  and  charter  within  their  own  management 
channels . 

More  importantly,  however,  this  user  oriented  viewpoint  provides 
improved  direction  for  current  and  future  work.  Fresh,  vital  information  is 
available  to  direct  research  into  channels  that  will  result  in  consolidation 
of  the  technology,  of  the  data,  of  the  theories,  of  the  phenomenological 
explanations.  Consolidation  of  the  state-of-the  technology  at  the  level 
that  is  most  appealing  to  the  user.  This  is  never  the  forefront  of  the  ST. 
This  is  the  work  that  is  from  two  to  four  years  old,  the  work  that  is  tending 
to  stabilize.  By  directing  research  to  fill  the  gaps  and  overcome  specific 
deficiencies  the  user  may  cite,  the  STM  can  cause  the  ST  to  be  more  immedi- 
ately useful  and  desirable  to  the  system  developer.  This  effort  is  invaluable 
to  the  ST  internally,  for  consolidation  of  results  will  ultimately  provide 
better  knowledge  with  which  to  direct  the  empirical  leading  edge  research 
in  the  technology. 
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IVhat  Docs  the  Systems  Developer  Do? 

Acquisition  management  within  the  DoD  is  a compendium  of  conflicting 
pressures.  Systems  in  development  are  envisioned  as  being  capable  of 
countering  future  threats,  threats  which  are  intrinsically  more  sophisti- 
cated than  those  in  the  field  today.  Such  threats  pose  the  imperative 
that  systems  currently  in  development  must,  themselves,  be  highly  sophisti- 
cated, Sophistication  costs  time  and  money.  The  greater  the  length  of  time 
in  development  is,  the  less  sophisticated  (relatively)  the  system  will  be 
when  finally  deployed,  and  the  more  the  acquisition  life  cycle  will  have 
cost.  A high  degree  of  sophistication  equates  to  an  increased  degree  of 
risk  during  the  development  phase  of  a program.  High  technical  risk 
increases  cost,  increases  testing  requirements  (and  difficulties)  and 
underwrites  the  probability  of  test  failures.  DoD  and  congressional 
pressure  today  is  pro  testing  and  con  failure  ...  but  pro  sophistication. 

Tlie  program  manager,  in  this  scenario,  instinctively  tends  to  minimice  his 
technical  risk  by  avoiding  new  technology  where  possible,  but  must  of 
necessity  employ  new  technology  if  he  is  to  field  a system  sophisticated 
enough  to  counter  the  future  threat.  Laboratories  offer  sophisticated 
technology  which,  from  their  point  of  view,  is  ready  for  application.  It 
never  is,  from  the  program  managers  point  of  view,  since  it  hasn't  been 
demonstrated  and  hasn't  been  fitted  to  his  constraints  and  unique  require- 
ments. It  is  easy  to  conceive  of  mediocrity  as  the  result  of  such  pressures. 

Historically,  program  offices  have  exuded  the  attitude  that  "its  our 
wheel,  and  we'll  invent  it  as  we  see  fit."  It  isn't  hard  to  envision 
where  this  attitude  comes  from.  If  you  are  confronted  with  "half-baked" 
technology  solutions  from  the  scientific  community  on  the  one  hand  and  the 


siren  song  of  the  prime  contractor  on  the  other  hand,  it  takes  little  or 
no  time  lor  communications  channels  between  the  program  office  and  the 
technical  community  to  atrophy.  No  amount  of  insistence  from  OSD  will 
facilitate  the  transfer  of  small  technologies  into  a major  program  once  the 
communications  are  gone.  IVhen  an  SPO  assumes  the  appearance,  to  the  tech- 
nology community,  of  an  unassailable  fort  then  the  potential  for  technology 
infusion  into  the  SPO  is  no  longer  orchestratable  by  bureaucratic  department 
heads  in  Washington,  D.C. 

The  program  office  staff  can  help  themselves  in  the  technology  transfer 
area.  Personal  involvement  is  the  most  certain  method  of  obtaining  insight 
into  systems  technology  needs  and  solutions.  Presupposing  the  existence 
of  technology  managers  who  wish  to  help,  the  program  office  personnel  have 
a role  to  play  which  they  must  individually  accept.  It  is  the  nature  of 
individual  attitudes  and  actions  of  program  office  personnel  that  is  to  be 
addressed  in  the  ensuing  paragraphs. 

The  program  manager  must  communicate  to  the  STM  the  true  nature  of 
his  technology  needs.  He  must  assist  the  STM  in  understanding  the  develop- 
ment program  problems  and  constraints.  This  requires  that  the  STM  be  edu- 
cated in  the  language  and  the  scenario  of  the  program.  The  STM  must  bo 
informed  of  the  system  peculiarities  and  requirements.  He  must  understand 
the  constraints  of  the  program,  the  criteria  that  technology  must  meet  to 
be  useful.  He  must  understand  the  program  well  enough  to  be  able  to  view 
his  technology  from  the  program  managers  point  of  view.  Program  documenta- 
tion, technical  explanations,  threat  discussions,  requirements  in  terms  of 
maintainability,  reliability,  and  integration  into  the  total  system  must  be 
learned,  understood. 
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Of  singular  importance  is  the  information  the  program  manager  can 
provide  as  to  why  a given  technology  is  viewed  as  inadequate  to  meet  the 
system's  needs.  Quantification  of  the  perceived  inadequacies  of  the  ST 
will  lead  to  areas  where  the  system  manager  can  be  educated  out  of  mis- 
conceptions, and  areas  where  the  STM  can  only  acknowledge  the  inadequacies 
of  the  ST.  If  the  SIM  is  perceptive,  if  the  program  manger  can  properly 
express  the  inadequacies  of  the  ST,  then  research  can  be  applied  to 
alleviate  the  shortcomings. 

The  program  manager  must  be  candid  concerning  the  potential  of  tlie  ST 
to  impact  his  program.  He  must  indicate  the  degree  of  likelihood  that  his 
program  has  time  or  need  for  the  ST.  He  must  reveal  his  skepticism  that 
the  ST  can  enhance  the  attainment  of  his  program  goals.  He  must,  after 
such  revelations,  acknowledge  the  rebuttal  offered  by  the  STM.  He  should 
be  willing  to  assess  the  position  of  the  Si'M,  and,  especially,  should 
encourage  the  STM  to  perform  consolidation  of  his  technology  to  meet  program 
objectives  if  time  constraints  permit. 

The  central  theme  that  should  be  retained  by  the  program  manager  and 
the  STM  throughout  the  exercise  of  the  above  ideas  is:  the  program  manager 
is  not  committed  to  utilization  of  the  ST.  He  views  it  as  inadequate  in  its 
current  state,  but  possessing  potential  to  impact  the  performance  capability 
of  his  system.  Ho  expresses  his  skepticism  concerning  the  ST,  but  is  willing 
(capable)  to  be  educated  concerning  the  true  state  of  the  ST.  It  is  the 
STM's  responsibility  to  consolidate  his  research  and  present  it  in  a manner 
that  is  compatible  with  the  program  requirements.  If  the  STM  can  do  this, 
then  the  program  manager  must  show  a degree  of  commitment. 

The  activities  beyond  this  point  of  agreement  are  the  activities 


associated  with  active  technology  transfer.  There  are  pitfalls  and  growing 
pains  to  be  lived  through.  There  is  a transfer  of  funding  responsibilities 
to  the  system  program  office  and  a period  during  which  the  ST  community 
must  work  closely  with  the  program  office,  providing,  for  a time,  engineering 
support  to  the  program.  Finally,  the  responsibility  for  the  ST  is  assumed 
by  the  development  program  and  the  ST  community  performs  only  an  advisory 
role.  Throughout  this  transition  period  (which  could  take  two  to  three 
years)  it  is  a mandate  that  both  parties  to  the  technology  accept  the 
premise  that  the  technology  is  immature.  The  immaturity  is  unavoidable  and 
can  only  be  retired  through  application  experience  in  systems. 
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CONCLUSION 

I'echnology  development  is  a large  segment  of  activity  within  the  UoU. 

In  general  terms  this  base  of  work  is  maintained  to  enhance  our  capability 
to  field  systems  adequate  to  meet  future  sopliisticated  threats.  Within 
the  spectrum  of  R^D  programs  conducted  by  the  UoU  there  are  sets  of  re- 
search which  might  properly  be  classified  as  large  technologies  and  small 
technologies.  Possibly  the  distinction  originates  in  how  urgently  the 
technology  is  needed  for  current  development  programs.  In  any  case  the 
large  technologies  are  invariably  linked  to  major  programs  and,  per  se, 
need  no  driving  force  to  sustain  or  Justify  the  major  research  work.  There 
is  no  question  of  technology  transition  here,  since  utilization  is  demon- 
stratable  in  major  systems. 

At  the  fringes  of  the  large  technology  programs,  and  in  broad  areas 
where  major  thrusts  do  not  currently  exist  there  arc  hundreds  of  small 
programs  underway  in  all  of  the  services  that  operate  under  the  aegis  that 
they  will  be  required  in  the  future.  In  point  of  fact,  many  of  these 
programs  address  teclinology  areas  that  could  be  handled  better.  In  point 
of  fact,  al 1 of  these  technologies  are  useful,  arc  interesting,  do  possess 
potential,  but  not  all  are  being  applied.  They  do  possess  areas  of  advance- 
ment that  have  not  been  utilized,  they  do  press  the  frontiers  of  technology 
and,  at  the  forefront,  are  in  a state  which  is  not  usable.  However,  many 
of  the  advances  that  have  been  made  have  not  been  transferred. 

The  blight  on  technology  transfer  is  primarily  a two  fault  syndrome. 
Program  managers  view  ST's  at  face  value  and  sec  a welter  of  conflicting 
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data,  theories,  phenomenological  explanations.  This  "moving  target"  of 
information  cannot  be  dealt  with  in  a program  office  because  of  lack  of 
intense  knowledge  of  the  area,  and  lack  of  time  to  gain  the  knowledge.  So, 
the  program  offices  discard  ST's  as  unusuable.  Small  technology  managers 
allow  this  to  happen.  Herein  lies  tlie  reason  for  the  demise  of  technology 
transfer.  The  technology  community  does  not  prepare  itself  to  present  use- 
ful information  to  potential  users.  It  girds  itself  in  an  array  of  con- 
flicting theories,  conflicting  data  bases  and  fuzcy  five  year  objectives 
and  emanates  tlie  "theory  confusion"  of  its  forefront  technology  investiga- 
tions. 

Small  technology  management  is  a personal  attitude  that  can  circumvent 
this  turn  of  events.  The  STM  attitude  encompasses  the  following: 

(1)  1 understand  my  technology  - across  my  service  component  - across  the 

other  service  components  - within  the  private  sector.  (2)  1 understand  the 

potential  for  use  of  my  ST  witliin  DoD  programs  under  development.  1 under- 
stand my  verifiable  technology  advances  - I understand  the  chaos  at  my 
technology  forefront.  (.3)  1 am  trying  to  understand  program  needs  and  my 

ST  deficiencies  relative  to  those  needs.  (4)  1 am  a buffer,  an  eclectic 

device  - 1 will  show  you  what  I can  prove. 

The  SI’O  must  match  this  personal  attitude  with  an  attudinal  change  on 
its  part.  The  program  management  attitude  must  bo  (1)  This  is  my  problem... 

(2)  Those  are  your  deficiencies  as  I perceive  them. . . (3)  Convince  me  of 
your  capability  and  I will  use  it. 

By  successfully  integrating  tliis  theme  of  attitudes,  tlic  STM  can  bring 
focus  to  his  ST,  can  define  the  area  usages  of  his  ST,  can  consolidate  his 
research,  can  present  his  abilities  in  a fashion  that  the  user  community 


can  accept.  In  short,  he  can  provide  the  force  to  consolidate  research 
developments  into  useful  application,  can  reorient  research  into  useful 
paths  (through  this  consolidation  process),  and  can  transfer  technology 
into  the  application  world. 
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